home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Software Vault: The Gold Collection
/
Software Vault - The Gold Collection (American Databankers) (1993).ISO
/
cdr11
/
adde13a.zip
/
ELUGUIDE.TXT
< prev
next >
Wrap
Text File
|
1993-06-26
|
10KB
|
182 lines
EchoList - The EchoMail Conference List Page 1
Users Guide as of: 21 Feb 1993
PURPOSE
This Users Guide is intended as a brief overview of the EchoList, and a
shortcut description of how to submit updates to the database. Probably 75%
of you will not need to know anything more about the process than what you
find here.
The companion Technical Reference document goes into much more detail on the
format of the update messages and on how the EchoList system itself works.
Those of you with insomnia will want to take a look at it right away.
The EchoList is a monthly publication which attempts to document certain
interesting information about EchoMail Conferences; "interesting" to people
who would like to participate, interesting to EchoMail Coordinators and those
who route the conference traffic, and potentially interesting to the
Conference Moderator. The base product of the EchoList database is the
detailed Conference listing. But, as needs are identified which can be
satisfied with the available information, additional reports and analyses can
be developed.
Basically, the EchoList is maintained by the Moderators who choose to
advertise their conferences here. Additions and updates to the database are
done by submitting NetMail messages addressed to a special name and node
address. The Subject of the message indicates what is to be done, and the
body of the message has the data for the database entry, formatted one
keyword and value per line. If you're familiar with AREAFIX or RAID message
formatting, this will give you no trouble.
In order to keep the EchoList clear of out-of-date information and dead
conferences, all entries expire six months after initially published. You
must send an update at least once every six months to maintain your EchoList
entry. Let me repeat: YOU maintain the EchoList entries--not me. I just
publish 'em.
ADDITIONS AND UPDATES
To add or update an EchoList entry, submit a NetMail message to "ECHOLIST" at
1:1/201. The message subject must be "MOD UPD". The body of the message
text has the data for database entry, formatted so that every line starts
with a special keyword that identifies the field name, followed by the data
to be put in that field. Most of the lines are optional. If you don't want
to supply data for a given field, don't include it in the message at all.
The only required fields are TAG, TITLE and MODERATOR.
The first line describing a conference entry is TAG. The other lines can
come in any order, but TAG must come first. I'll list the keywords and flags
in a typical message followed by a brief description of each. For a more
detailed description refer to the Technical Reference. The CAPITALIZED part
of the keyword is the minimum abbreviation you can use. The To-name,
subject, keywords and passwords are NOT case sensitive.
To add or update an EchoList Entry send a NetMail message:
To: ECHOLIST
Copyright (c) 1993 by Michael G. Fuchs
EchoList - The EchoMail Conference List Page 2
Users Guide as of: 21 Feb 1993
At: 1:1/201
Subject: MODerator UPDate
In the body of the message:
TAGname <symbolic area name> /NOSHow
TITLe <brief title for sorting>
DESCription <A full description of the conference, audience, topics...>
MODerator <moderator name>, <moderator node>
PASSword <current password>, <new password>
TOTalnodes <number of nodes carrying this conference>
VOLume <number of messages>/<Month or Day or Week>
RESTrictions /SYSop /MOD-apvl /MEMber
ORIGin <origination node of the distribution
DISTribution <distribution areas or vehicles of note>
GATEway <gateways to other zones & networks crossed>
SEENby <node list>
PATH <node-pair list>
---
The TAG is obviously the one-word symbolic name used in distributing the
conference; also called the AREA name or GROUP name. If you are paranoid
about unauthorized links to a privately distributed conference, you can
follow the tagname with a space and /NOSHOW. This will record the conference
appropriately but not include the tagname in reports (it'll say <hidden>).
TITLE should be a one-line title for the conference, preferably 70 chars or
less, preferably starting with a word which will make finding it in a sorted
list sensible (avoid starting with A, An, The, ...).
DESCRIPTION allows for a longer description of the conference, and you can
supply multiple DESC lines and they will be appended. Don't bother trying
fancy formatting. All the lines are combined and word-wrapped into a single
paragraph.
Next to title, MODERATOR is one of the most important fields. The EchoList
definition of a Moderator is someone with authority over the internal
operation of a conference, with the right to state the description and
policies within it. You MUST list at least one Moderator in order to have a
valid EchoList entry. You can list as many as you want. Each Moderator line
consists of a first and last name followed by their Node Address. You only
put ONE NAME AND ADDRESS PER LINE. If you have more than one alias address,
and you feel it's absolutely essential you advertise them, enter multiple
MODERATOR lines with your name, but different addresses on each. This is a
good time to explain how the EchoList stores Node Addresses.
NODE ADDRESSES -- The EchoList supports "5-D" or "Domain" addressing
throughout--with a twist. All places in the EchoList where you can use a
node address support the full notation: zzz:ttt/nnn.ppp@ddddddd, where zzz
is the zone number, ttt is the net, nnn is the node, ppp is the point (if
applicable), and ddd is the Domain. Zone, net, node and point are each
integer fields. Domain is a text field than cannot contain spaces. There's
more detail on how defaults are handled in the Tech Ref. The twist is that
the EchoList allows use of the Domain field by itself to specify non-FidoNet
Copyright (c) 1993 by Michael G. Fuchs
EchoList - The EchoMail Conference List Page 3
Users Guide as of: 21 Feb 1993
addresses. Lets say, for example, you wanted to list your Compuserve user id
as an alternate address, you could enter:
MOD Mike Fuchs, 1:266/71@fidonet.org
MOD Mike Fuchs, @CIS-72760.3326
But who'd want to do that... Ah well, it's a Lucky Strike extra I threw in
to the NODE_ADDRESS processing routines.
The PASSWORD field is not required. If you assign one, you must use it in
every change you make from then on, and it may protect your entry from
modification by someone else. There are two password fields. The first is
for the current password. The second is for the new password to change it
to, if you want to change it.
TOTALNODES is for publishing a rough estimate of the number of systems
participating in your conference. It's optional. If supplied, save the
editorials--it's just a single integer number.
VOLUME is for advertising a rough estimate of the volume of messages to be
expected by those who link-in. It's optional. If specified it MUST be a
single integer number followed by a slash followed by either MONTH, WEEK or
DAY to identify the time period in which that number of messages flow.
RESTRICTIONS is a shorthand reference to rules applied by the Moderator
concerning admission to the conference. /SYSOP means only Sysops are allowed
to participate, /MEMBER means you must be validated as a member of some
organization in order to participate (eg: MENSA), and /MOD-APVL means you can
not link in without specific approval of the Moderator.
ORIGIN, DISTRIBUTION and GATEWAYS are just an organized set of text fields
you can use to describe sources and contacts that control links to the
conference. Use none, any or all of them as you see fit. If you are on a
formal distribution backbone of some kind, don't just say BACKBONE--there are
lots of them. Specifically say "Zone 1 Backbone" or "Zone-3 Backbone" or
"EchoNet Backbone"...
SEENBY lines let you document where your conference appears. This is a total
waste of space for backbone-type conferences. Saying you're on a backbone in
the DISTRIBUTION field above should be more than adequate. If you use it for
a privately distributed conference, list the node numbers the way you'd see
them on an EchoMail message (except these can include Zone, Domain and
Point). Like EchoMail seen-by lines, if you leave off the Domain, Zone or
Net, it'll be inherited from the previous seen-by node address.
PATH lines let you document specific routing connections as pairs of
connected node addresses. If you want to use these, look at the Tech Ref for
an explanation.
That's a brief look. There's a lot more detail in the Technical Reference.
And I haven't even discussed the KEY or OPTIONS lines. And there are message
formats for deleting EchoList entries and for submitting Conference Rules
files for inclusion in a combined archive of rules. You probably should,
eventually, look over the Tech Ref. Enjoy.
Copyright (c) 1993 by Michael G. Fuchs